-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http_parser: use MakeCallback
#5419
Conversation
@@ -104,6 +106,7 @@ function expectBody(expected) { | |||
assert.throws(function() { | |||
parser.execute(request, 0, request.length); | |||
}, Error, 'hello world'); | |||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@indutny Why did you disable this test in your original PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it pass now?
If I remember it right it just killed the process with uncaught exception last time (FatalException
or whatever).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does on my machine. Running CI again to see if it does.
a39c50d
to
7e7d2f3
Compare
There are a lot of failures for |
One more time to see if the previous was a fluke |
All but one failure was for linux-fips: freebsd: win10-vcbt2015: win2012r2-vs2015: @rvagg Maybe you have an idea how to proceed, or maybe something is going on w/ Jenkins? |
@indutny confirmed that switching to |
7e7d2f3
to
606c839
Compare
CI: https://ci.nodejs.org/job/node-test-pull-request/1788/ @indutny I've added two The reason the pipeline flood fix worked before was because the entire packet of requests was essentially processed synchronously. But calling In the case of The reason In the end I believe this fix is the simplest, and keeps the parser operating like it did before. |
Ah, yeah. Nice catch! I was going to take a look at it, but you beat me 😉 |
LGTM if it works |
Make `HTTPParser` an instance of `AsyncWrap` and make it use `MakeCallback`. This means that async wrap hooks will be called on consumed TCP sockets as well as on non-consumed ones. Additional uses of `AsyncCallbackScope` are necessary to prevent improper state from progressing that triggers failure in the test-http-pipeline-flood.js test. Optimally this wouldn't be necessary, but for the time being it's the most sure way to allow operations to proceed as they have. Fix: nodejs#4416 PR-URL: nodejs#5419 Reviewed-By: Fedor Indutny <fedor@indutny.com>
606c839
to
a7e49c8
Compare
Thanks much. CI is all green. Landed in a7e49c8. |
@trevnorris ... are you going to want to pull this back into v4 at all? If not, can you mark it don't land? |
I think the goal is still to backport all the asyncwrap stuff? |
Make `HTTPParser` an instance of `AsyncWrap` and make it use `MakeCallback`. This means that async wrap hooks will be called on consumed TCP sockets as well as on non-consumed ones. Additional uses of `AsyncCallbackScope` are necessary to prevent improper state from progressing that triggers failure in the test-http-pipeline-flood.js test. Optimally this wouldn't be necessary, but for the time being it's the most sure way to allow operations to proceed as they have. Fix: #4416 PR-URL: #5419 Reviewed-By: Fedor Indutny <fedor@indutny.com>
As @Fishrock123 said, all the AsyncWrap changes will need to be back ported if it is to maintain compatibility. |
Oh hey all. It looks like this commit has created a regression on v5.7.1. Specifically throwing inside of a call back to an http.get request is not throwing :sad: Here is a gist for the test I was using https://gist.github.com/TheAlphaNerd/6615a27684deb682dfe7 You will notice that the setTimeout is commented out... adding set timeout actually fixes this problem 😢 |
Based on the regression created by this change I'm going to assume we are not going to land it on v4. @trevnorris let me know if the plans for v4 and asyncwrap changes |
I think this probably needs to find its way into LTS but can do so after a longer wait, it fills in the AsyncWrap picture more and the discrepancy between LTS and Stable will be non-trivial if it doesn't land there, and we're getting close to deciding on "official" support for AsyncWrap too. @thealphanerd I'm going to switch back to lts-watch but we need good settling time for this given the regression. |
@rvagg SGTM. I'll remove the don't land label from the regression fix |
@thealphanerd The regression was fixed in 3521b05. As @rvagg said this is not absolutely necessary for backport, but it shouldn't be a problem to backport with the fix. |
Make `HTTPParser` an instance of `AsyncWrap` and make it use `MakeCallback`. This means that async wrap hooks will be called on consumed TCP sockets as well as on non-consumed ones. Additional uses of `AsyncCallbackScope` are necessary to prevent improper state from progressing that triggers failure in the test-http-pipeline-flood.js test. Optimally this wouldn't be necessary, but for the time being it's the most sure way to allow operations to proceed as they have. Ref: #7048 Fix: #4416 PR-URL: #5419 Reviewed-By: Fedor Indutny <fedor@indutny.com>
Make `HTTPParser` an instance of `AsyncWrap` and make it use `MakeCallback`. This means that async wrap hooks will be called on consumed TCP sockets as well as on non-consumed ones. Additional uses of `AsyncCallbackScope` are necessary to prevent improper state from progressing that triggers failure in the test-http-pipeline-flood.js test. Optimally this wouldn't be necessary, but for the time being it's the most sure way to allow operations to proceed as they have. Ref: #7048 Fix: #4416 PR-URL: #5419 Reviewed-By: Fedor Indutny <fedor@indutny.com>
Make `HTTPParser` an instance of `AsyncWrap` and make it use `MakeCallback`. This means that async wrap hooks will be called on consumed TCP sockets as well as on non-consumed ones. Additional uses of `AsyncCallbackScope` are necessary to prevent improper state from progressing that triggers failure in the test-http-pipeline-flood.js test. Optimally this wouldn't be necessary, but for the time being it's the most sure way to allow operations to proceed as they have. Ref: #7048 Fix: #4416 PR-URL: #5419 Reviewed-By: Fedor Indutny <fedor@indutny.com>
Make `HTTPParser` an instance of `AsyncWrap` and make it use `MakeCallback`. This means that async wrap hooks will be called on consumed TCP sockets as well as on non-consumed ones. Additional uses of `AsyncCallbackScope` are necessary to prevent improper state from progressing that triggers failure in the test-http-pipeline-flood.js test. Optimally this wouldn't be necessary, but for the time being it's the most sure way to allow operations to proceed as they have. Ref: #7048 Fix: #4416 PR-URL: #5419 Reviewed-By: Fedor Indutny <fedor@indutny.com>
Make
HTTPParser
an instance ofAsyncWrap
and make it useMakeCallback
. This means that async wrap hooks will be called onconsumed TCP sockets as well as on non-consumed ones.
Fix: #4416
This PR overrides #4509.
R= @indutny
R= @bnoordhuis